Database insert with deferred materialization

ABSTRACT

According to one embodiment of the present invention, a system inserts data into a database object. The system associates the database object with a parameter specifying materialization of data for the database object. The system inserts data into the database object and materializes the data in accordance with the parameter to provide access to the data from the database object, wherein the parameter specifies a portion of the data to be materialized upon insertion. Embodiments of the present invention further include a method and computer program product for inserting data into a database object in substantially the same manners described above.

BACKGROUND

1. Technical Field

Present invention embodiments relate to database insert operations, and,more specifically, to insert operations with deferred or partialmaterialization.

2. Discussion of the Related Art

Database management systems (DBMSs) for online transaction processing(OLTP) manage high insert transaction rates generated by increasingnumbers of data producing devices. A common measure of insertperformance is external throughput rate (ETR), defined as the number ofcompleted transactions divided by elapsed time.

To insert data into a table, a DBMS physically writes the data tostorage designated for the table data (e.g., to pages in a table space),updates indexes for the table, and writes a record of the insertoperation to the database log to ensure that the transaction isrecoverable. Physically writing to the table requires locking pages orrows in the table and searching to determine where free space exists inthe table storage area. The time consumed by these activities affectsinsert performance.

Multithreading can be used to increase insert throughput. However, sincemultithreading leads to concurrent insert processing with conflicts, ETRdoes not scale linearly with the number of concurrent threads.

BRIEF SUMMARY

According to one embodiment of the present invention, a system insertsdata into a database object. The system associates the database objectwith a parameter specifying materialization of data for the databaseobject. The system inserts data into the database object andmaterializes the data in accordance with the parameter to provide accessto the data from the database object, wherein the parameter specifies aportion of the data to be materialized upon insertion. Embodiments ofthe present invention further include a method and computer programproduct for inserting data into a database object in substantially thesame manners described above.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Generally, like reference numerals in the various figures are utilizedto designate like components.

FIG. 1 is a diagrammatic illustration of an example computingenvironment for an embodiment of the present invention.

FIG. 2 is block diagram depicting example information stored andaccessed by an insert module and deferred materializer according to anembodiment of the present invention.

FIG. 3 is a flow diagram illustrating an example manner of handlinginsert instructions according to an embodiment of the present invention.

FIG. 4 is a flow diagram illustrating an example manner of materializingdeferred inserts according to an embodiment of the present invention.

DETAILED DESCRIPTION

Present invention embodiments insert data into a database object withoutimmediately materializing all of the inserted data. For example, adatabase table may be designated for deferred materialization. When arow is inserted into the table, the row data and table identifier arerecorded in the database log, but the row data is not immediatelywritten to the table storage space. An asynchronous process may thenread the data from the log and write the data to the table storagespace.

One aspect of a present invention embodiment is to improve insertperformance where the inserted data need not be promptly available forreading. An example is an audit table for access to customer data in adatabase. An auditor may need to access the audit data, but typicallythe auditor does not analyze the data immediately after a record isinserted in the table. Another example is text message history. Serviceproviders generally preserve users' past text messages, but, aftertransmission, old text message content is rarely, if ever, accessed.Database workloads handling inserts of audit, history, or similar dataneed not write the data into the table or update indexes because thedata need not be accessed immediately.

An example computing environment for a present invention embodiment isillustrated in FIG. 1. Specifically, the environment includes serversystems 100, and one or more client or end-user systems 110. Serversystems 100 and client systems 110 may be remote from each other andcommunicate over a network 120.

Network 120 may be implemented by any number of any suitablecommunications media (e.g., wide area network (WAN), local area network(LAN), Internet, intranet, etc.). Alternatively, any number of serversystems 100 and client systems 110 may be local to each other, andcommunicate via any appropriate local communication medium (e.g., localarea network (LAN), hardwire, wireless link, intranet, etc.).

A server system 100 may include a database management system (DBMS) 102for storing and accessing data in storage system 130. The DBMS includesinsert module 104 and deferred materializer 106. Insert module 104processes insert instructions (e.g., SQL INSERT statements or other datamanipulation language statements to insert data into a data object)submitted to the DBMS (e.g., by client system 110 via network 120).Storage system 130 includes log 132, table data 134, and metadata 136.The DBMS and storage system may be implemented across plural serversystems. Alternatively, the storage system, DBMS, insert module, and/ordeferred materializer may reside on a client system 110 or othercomputer system in communication with the client system and/or serversystem.

Client systems 110 may include a database client 112 to enable users tocommunicate with the DBMS (e.g., via network 120). The client systemsmay present any graphical user (e.g., GUI, etc.) or other interface(e.g., command line prompts, menu screens, etc.) for the database clientand/or other applications to receive commands from users and interactwith the DBMS and/or other modules or services.

Server systems 100 and client systems 110 may be implemented by anyconventional or other computer systems preferably equipped with adisplay or monitor, a base (e.g., including at least one processor 20,memories 30 and/or internal or external network interface orcommunications devices 10 (e.g., modem, network cards, etc.), optionalinput devices (e.g., a keyboard, mouse, or other input device), and anycommercially available and custom software (e.g., DBMS software, insertmodule software, deferred materializer software, etc.). Storage system130 may be implemented by any number of conventional or other, local orremote storage devices (e.g., magnetic disk drives, tape drives, solidstate devices, etc.).

The DBMS, insert module, and deferred materializer may include one ormore modules or units to perform the various functions of presentinvention embodiments described below (e.g., processing commits,processing reads, logging transactions, indexing, managing metadata,materializing table data, etc.), may be implemented by any combinationof any quantity of software and/or hardware modules or units, and mayreside within memory 30 of a server system and/or client systems forexecution by processor 20.

A block diagram of example information stored and accessed by insertmodule 104 and deferred materializer 106 according to an embodiment ofthe present invention is illustrated in FIG. 2. For each table (or groupof tables), metadata 136 may include, e.g., a materialization parameter200 and log pointers 201, 202, 203, and 204 (e.g., log record sequencenumbers (LRSNs), relative byte addresses (RBAs), etc.). Insert module104 processes inserts to a table based on the table's materializationparameter. The parameter may include any suitable values to indicate amaterialization mode. The materialization parameter may indicate amaterialization mode from among, e.g., the following:

1. MATERIALIZE NONE

2. MATERIALIZE DEFERRED

3. MATERIALIZE INDEX ONLY

4. MATERIALIZE IMMEDIATE.

The mode MATERIALIZE NONE specifies that neither insert module 104 nordeferred materializer 106 physically write the inserted data into tabledata 134. Thus, the data will not be available to be read after theinsert operation. All read access attempts may be rejected with, e.g.,an indication that the resource is unavailable.

MATERIALIZE NONE may be used, e.g., in a mirrored system where the datais inserted in the mirrored system and then propagated (from log 132 ofthe first system) to another system for full read access. In thisscenario, physically writing the data into the table data of themirrored system may be avoided. This eliminates the bottlenecks oflocking, performing space searches, and updating indexes. The insertmodule merely writes a record containing the inserted data and a tableidentifier (e.g., database identifier (DBID), objection identifier(OBID), etc.) to log 132. The primary limit on insert throughputtypically then becomes the logging rate. If the data must later beaccessed using the mirrored system, a table's materialization parametermay be altered, e.g., from MATERIALIZE NONE to MATERIALIZE DEFERRED, toinitiate asynchronous materialization of the data written to the log asdescribed below.

The mode MATERIALIZE DEFERRED specifies that the insert module writeinserted data to log 132 but not to table data 134, as described above.In addition, the insert module may set log pointers 201 and 202, and mayinitiate a process running deferred materializer 106. Log pointers 201and 202 define a range in the log that deferred materializer 106 mayscan for records of deferred inserts to materialize. In particular, theinsert module may set log pointer 201 to the lowest position in the logfor a record of a deferred insert and set log pointer 202 to the highestlog position of a commit for a transaction with a deferred insert. Insetting log pointers 201 and 202, contention may occur only at a commit(when log pointer 202 is set) or at the first insert (when log pointer201 is set); the cost of this contention is low compared to conventionalmaterialization for transactions with many inserts.

The deferred materializer runs asynchronously to the insert module(e.g., as a child process of the insert module, a child process of theDBMS, a daemon, etc.). The deferred materializer reads log 132, extractsthe inserted data, writes the data to table data 134, and updatesindexes. In addition, the deferred materializer may track metadata forrobust fault tolerance. For example, the deferred materializer may writethe log position of the lowest record for which materialization has yetto commit to log pointer 203, and write the highest log position of acommit record for fully materialized data to log pointer 204.

When a user accesses data in a table for which the materializationparameter indicates MATERIALIZE DEFERRED, the system may warn the userthat data inserted into the table may not yet have been materialized.For example, in a DB2® environment, the system may warn the user byreturning a positive SQLCODE.

The mode MATERIALIZE INDEX ONLY specifies a hybrid procedure. As in thecase of MATERIALIZE DEFERRED, the insert module writes the inserted datato log 132, writes log pointers 201 and 202, and does not write the datato table data 134. However, the insert module also synchronously buildsindexes for the table. The index for an inserted row contains a pointerto the log record (e.g., LRSN, RBA, etc.) that contains the inserted rowdata, rather than a row identifier that points into the table data. Thisallows readers to access the inserted data in a predictable andrepeatable manner as soon as the insert module completes processing ofthe insert statement. The DBMS processes a user's read request byfinding the pointer to the log in the index, and retrieving the datafrom the log. By not placing the data in the table data, the bottlenecksof space map searches and lock contention on the data pages areeliminated. The deferred materializer then writes the row data to thetable data and updates the indexes by replacing pointers to log recordswith row identifiers.

The MATERIALIZE IMMEDIATE mode specifies essentially the defaultbehavior for traditional RDBMS systems. For example, the system maywrite the row data to the table data, write to the table's index, andwrite separate log records after each of the table and index writeoperations.

A manner in which the insert module processes insert statements (e.g.,SQL INSERT statements or other DML insert statements) in a deferredmaterialization mode (e.g., MATERIALIZE NONE, MATERIALIZE DEFERRED,MATERIALIZE INDEX ONLY) according to an embodiment of the presentinvention is illustrated in FIG. 3. In particular, the insert modulereceives an insert statement for inserting data into a table in adeferred materialization mode at step 310.

At step 320, the insert module determines whether the materializationparameter associated with the table indicates MATERIALIZE IMMEDIATE. Ifso, the insert module writes the row data to table data 134, updates thetable index, and writes to log 132 entries for the write to the tabledata and the update to the index. Processing then ends.

If the materialization parameter does not indicate MATERIALIZE IMMEDIATEat step 320, the insert module determines whether the materializationparameter indicates MATERIALIZE NONE at step 330. If so, the insertmodule writes a record to log 132 at step 332. This record contains therow data to insert and indicates that the insert has not beenmaterialized (by, e.g., including the materialization parameter or otherflag, writing a null value in place of a reference into the table data,etc.). Processing then ends.

If the materialization parameter does not indicate MATERIALIZE NONE atstep 330, the insert module determines whether the materializationparameter indicates MATERIALIZE DEFERRED at step 340. If so, the insertmodule writes a record to log 132 at step 342. This record contains therow data to insert and indicates that the insert has not beenmaterialized (by, e.g., including the materialization parameter or otherflag, writing a null value in place of a reference into the table data,etc.). Processing then ends.

If the materialization parameter does not indicate MATERIALIZE DEFERREDat step 340, the insert module determines whether the materializationparameter indicates MATERIALIZE INDEX ONLY at step 350. If so, theinsert module writes a record to log 132 at step 352. This recordcontains the row data to insert and indicates that the insert has notbeen materialized (by, e.g., including the materialization parameter orother flag, writing a null value in place of a reference into the tabledata, etc.). At step 354, an entry for the inserted data is added to thetable's index. The index may be created if it does not yet exist (e.g.,if this is the first row inserted to the table, and creation of thetable was deferred when the table was created). This index entryincludes a pointer to the log position of the record written at step 352where the data may be found. Processing then ends.

An example manner of materializing deferred inserts according to anembodiment of the present invention is illustrated in FIG. 4. Inparticular, at step 410, the deferred materializer finds the logposition of the first log record to scan for deferred inserts. Forexample, the first log record to scan may be indicated by log pointer201. At step 420, the deferred materializer reads the log record at thecurrent log position. At step 430, the deferred materializer examinesthe log record and determines whether the record corresponds to aninsert instruction for a table designated for deferred materialization(e.g., a table having a materialization parameter indicating MATERIALIZEDEFERRED or MATERIALIZE INDEX ONLY). If not, processing proceeds to step460.

Otherwise, the deferred materializer determines whether thematerialization parameter indicates MATERIALIZE DEFERRED at step 440. Ifso, the deferred materializer extracts the row data from the log recordat step 442, writes the data into table data 134 at step 444, andupdates the index at step 446. Since the deferred materializer need notmaterialize data synchronously with the insert module, it may performfull space searching and place data in clustering order to optimizelater read access.

If the materialization parameter does not indicate MATERIALIZE DEFERREDat step 440, the deferred materializer determines whether thematerialization parameter indicates MATERIALIZE INDEX ONLY at step 450.If so, the deferred materializer extracts the row data from the logrecord at step 452, writes the data into table data 134 at step 454, andreplaces the pointer into log 132 in the row index with a pointer intotable data 134 at step 456. As in the case of MATERIALIZE DEFERRED, thedeferred materializer need not materialize data synchronously with theinsert module, and therefore the deferred materializer may perform fullspace searching and place data in clustering order to optimize laterread access. If the materialization parameter does not indicateMATERIALIZE INDEX ONLY at step 450, processing proceeds to step 460.

At step 460, the deferred materializer moves to the position of the nextrecord to read in the log. At step 470 the deferred materializerdetermines whether it has finished its scan of the log. For example, thedeferred materializer may compare the position of the current record tolog pointer 202 to determine whether the end of the range of records toscan has been reached. If so, the procedure ends. Otherwise, processingreturns to step 420.

The deferred materializer may run according to any schedule, using anymanner of determining which log records to scan. For example, the DBMSmay launch a deferred materializer process for each transaction thatincludes a deferred insert (e.g., MATERIALIZE DEFERRED or MATERIALIZEINDEX ONLY). In this case, the insert module may set the point at whichthe deferred materializer process will start to scan the log by savingthe log position of the record for the first deferred insert as logpointer 201. To set an end point for the scan, the DBMS may write thelog position of the commit record for the transaction as log pointer202. The DBMS may launch the deferred materializer process for thetransaction when, e.g., log pointer 201 is written, log pointer 202 iswritten, or any other time. Alternatively, the DBMS may run deferredmaterializer processes according to a schedule (e.g., hourly, daily,weekly, when a predefined number of records or transactions have beenprocessed, etc.), where the deferred materializer initially beginsscanning the log at the earliest position that may contain a deferredinsert record, saves the log position to which it has progressed whenthe process ends, and resumes at that position when the deferredmaterializer is restarted.

The deferred materializer may run on a separate processor than theinsert module (e.g., on a multiprocessor server, on a separate server,etc.). On a System z® platform, the deferred materializer may run on anIBM System z Integrated Information Processor (zIIP) to limit chargeableprocessing time.

It will be appreciated that the embodiments described above andillustrated in the drawings represent only a few of the many ways ofimplementing embodiments for inserting data into a database object.

The topology or environment of the present invention embodiments mayinclude any number of computer or other processing systems, data storagesystems, arranged in any desired fashion, where the present inventionembodiments may be applied to any desired type of computing environment(e.g., cloud computing, client-server, network computing, mainframe,stand-alone systems, etc.). The computer or other processing systemsemployed by the present invention embodiments may be implemented by anynumber of any personal or other type of computer or processing system(e.g., desktop, laptop, PDA, mobile devices, etc.), and may include anycommercially available operating system and any commercially availableor custom software (e.g., database software, communications software,etc.). These systems may include any types of monitors and input devices(e.g., keyboard, mouse, voice recognition, touch screen, etc.) to enterand/or view information.

The various functions of the computer or other processing systems may bedistributed in any manner among any number of software and/or hardwaremodules or units, processing or computer systems and/or circuitry, wherethe computer or processing systems may be disposed locally or remotelyof each other and communicate via any suitable communications medium(e.g., LAN, WAN, intranet, Internet, hardwire, modem connection,wireless, etc.). For example, the functions of the present inventionembodiments may be distributed in any manner among various serversystems, end-user/client and/or any other intermediary processingdevices including third party client/server processing devices. Thedeferred materializer may run on a separate processor than the insertmodule (e.g., on a multiprocessor server, on a separate server, etc.).On a SYSTEM Z® platform, the deferred materializer may run on a zIIPprocessor to limit chargeable processing time. The software and/oralgorithms described above and illustrated in the flow charts may bemodified in any manner that accomplishes the functions described herein.In addition, the functions in the flow charts or description may beperformed in any order that accomplishes a desired operation.

The communication network may be implemented by any number of any typesof communications network (e.g., LAN, WAN, Internet, Intranet, VPN,etc.). The computer or other processing systems of the present inventionembodiments may include any conventional or other communications devicesto communicate over the network via any conventional or other protocols.The computer or other processing systems may utilize any type ofconnection (e.g., wired, wireless, etc.) for access to the network.Local communication media may be implemented by any suitablecommunication media (e.g., local area network (LAN), hardwire, wirelesslink, Intranet, etc.).

The system may employ any number of data storage systems and structuresto store information. The data storage systems may be implemented by anynumber of any conventional or other databases (e.g., relational, objectoriented, etc.), file systems, caches, repositories, warehouses, etc.The system may be implemented for any DBMS on any platform.

The present invention embodiments may employ any number of any type ofuser interface (e.g., Graphical User Interface (GUI), command-line,prompt, etc.) for obtaining or providing information, where theinterface may include any information arranged in any fashion. Theinterface may include any number of any types of input or actuationmechanisms (e.g., buttons, icons, fields, boxes, links, etc.) disposedat any locations to enter/display information and initiate desiredactions via any suitable input devices (e.g., mouse, keyboard, touchscreen, pen, etc.).

It is to be understood that the software of the present inventionembodiments could be developed by one of ordinary skill in the computerarts based on the functional descriptions contained in the specificationand flow charts illustrated in the drawings. Further, any referencesherein of software performing various functions generally refer tocomputer systems or processors performing those functions under softwarecontrol. The computer systems of the present invention embodiments mayalternatively be implemented by any type of hardware and/or otherprocessing circuitry.

The present invention embodiments are not limited to the specific tasks,algorithms, parameters, data, or network/environment described above,but may be utilized for deferred and/or incomplete materialization ofany data. Any metadata items may be stored by any modules in any storagesystems, and any procedures for scanning the log to materialize deferredinserts may be used (e.g., scanning the range defined by log pointers201 and 202, scanning a complete log, scanning a range corresponding atime during which a table was designated for a particular manner ofmaterialization, etc.).

The deferred materializer may run at any time. For example, the insertmodule may start a deferred materializer process when it first insertsdata for a table designated for deferred materialization, e.g., at step360 (FIG. 3). Alternatively, the DBMS may start the deferredmaterializer at prescheduled times, ad hoc times, etc.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”,“comprising”, “includes”, “including”, “has”, “have”, “having”, “with”and the like, when used in this specification, specify the presence ofstated features, integers, steps, operations, elements, and/orcomponents, but do not preclude the presence or addition of one or moreother features, integers, steps, operations, elements, components,and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

What is claimed is:
 1. A system for inserting data into a databaseobject comprising: at least one processor configured to: associate thedatabase object with a parameter specifying materialization of data forthe database object; upon receiving a request to insert data into thedatabase object, bypass the database object and insert the data directlyinto a database log; and insert the data from the database log into thedatabase object and materialize the data in accordance with theparameter to provide access to the data from the database object,wherein the parameter specifies a portion of the data to be materializedupon insertion.
 2. The system of claim 1, wherein the parameterspecifies that no data is to be materialized upon insertion into thedatabase object, thereby precluding reading of the data from thedatabase object.
 3. The system of claim 1, wherein the parameterspecifies deferred materialization and the materialization is performedasynchronously to the data insertion.
 4. The system of claim 3, whereinthe processor is further configured to: insert the data into a databaselog; and wherein the materialization includes: identifying data in thedatabase log associated with deferred materialization and extractingidentified data from the database log designated for insertion into thedatabase object; and materializing the extracted data within thedatabase object and one or more indexes to provide access to the datafrom the database object.
 5. The system of claim 1, wherein theparameter specifies materialization of an index and the data isaccessible upon insertion.
 6. The system of claim 5, wherein thematerialization is performed asynchronously to the data insertion, andthe processor is further configured to: insert the data into a databaselog and construct the index with pointers to the database log to provideaccess to the data; and wherein the materialization includes:identifying data in the database log associated with the indexmaterialization and extracting identified data designated for insertioninto the database object; and materializing the extracted data withinthe database object and one or more indexes to provide access to thedata from the database object.
 7. The system of claim 2, wherein theprocessor is further configured to: insert the data into a database log;and read the log to replicate the database object.
 8. A computer programproduct for inserting data into a database object comprising: a computerreadable storage device having computer readable program code embodiedtherewith for execution on a processing system, the computer readableprogram code comprising computer readable program code configured to:associate the database object with a parameter specifyingmaterialization of data for the database object; upon receiving arequest to insert data into the database object, bypass the databaseobject and insert the data directly into a database log; and insert thedata from the database log into the database object and materialize thedata in accordance with the parameter to provide access to the data fromthe database object, wherein the parameter specifies a portion of thedata to be materialized upon insertion.
 9. The computer program productof claim 8, wherein the parameter specifies that no data is to bematerialized upon insertion into the database object, thereby precludingreading of the data from the database object.
 10. The computer programproduct of claim 8, wherein the parameter specifies deferredmaterialization and the materialization is performed asynchronously tothe data insertion.
 11. The computer program product of claim 10,wherein the materialization includes: identifying data in the databaselog associated with deferred materialization and extracting identifieddata from the database log designated for insertion into the databaseobject; and materializing the extracted data within the database objectand one or more indexes to provide access to the data from the databaseobject.
 12. The computer program product of claim 8, wherein theparameter specifies materialization of an index and the data isaccessible upon insertion.
 13. The computer program product of claim 12,wherein the materialization is performed asynchronously to the datainsertion, and the computer readable program code is further configuredto: insert the data into a database log and construct the index withpointers to the database log to provide access to the data; and whereinthe materialization includes: identifying data in the database logassociated with the index materialization and extracting identified datafrom the database log designated for insertion into the database object;and materializing the extracted data within the database object and oneor more indexes to provide access to the data from the database object.